package lecture;

/* CLASS
 * 
 * SRP - Single Responsibility Principle
 * 	 - it doess it all
 * 	 - it does it well
 * 	 - it does it only
 * 
 * LSP - Liskov Substitution Principle
 * 	 - functions that use pointers or references to base classes must be
 *     able to use objects of the derived classes without knowing it
 * 
 * LoD - Law of Demeter
 * 	 - users of class shouldn't know internals, just speak to interface
 * 	 - only speaks to 
 *   - not to give to world construction parameters
 *   - give to world business parameters
 * 
 * OCP - 
 * 
 * ISP - Interface Segregation Principle
 * 	 - clients should not be forced to depend upon services they do not use
 * 	 - avoid fat interfaces
 * 	 - separate clients mean separate interfaces
 * 
 * DEPENDENCIES
 * 
 * MDP - Minimal Dependencies Principle
 * 
 * DIP - Dependency Inversion Principle
 * 	 - high levels modules should not depend upon low-level ones, both
 * 	   should depend upon abstractions
 *   - should be interface dependencies
 * 
 * ADP - Acyclic Dependencies Principle
 * 	 - the dependency structure between entities (classes, packages, functions)
 * 	   must be a Dircted Acyclic Graph (DAG)
 * 	 - how to fight? extract interfaces
 * 
 * PACKAGES DESIGN PRINCIPLES
 * 
 * CCP - Common Closure Principle
 * 	 - classes within the package should be affected by the same kind of changes
 * 	   either al open, or all closed to the kind of change
 * 
 * REP - Reuse-Release Equivalence Principle
 * 	 - the unit of reuse is the unit of release the unit is wwhat UML refers to as a package
 * 	 - classes should be grouped into packages according to how they will be reused
 * 	 - to be effectively reused packages must be given a release number
 * 
 * CRP - Common Reuse Principle
 *   - the classes in a package are to be reused together 
 *   - reusers should depend upon the entire package, not just a part of it
 *   - ISP scaled to packages
 * 
 * SDP - Stable Dependencies Principle
 *   - a package should only depend upon packages that are more stable than itself
 *   - stability is a measure of difficulty in changeing  a package
 *   - what makes a package hard to change
 *   
 * SAP - Stable Abstractions Principle
 *   - the more abstract the better
 *  
 * Design Patterns
 * Creational: abstract factory., builder, prototype, singleton
 * 
 * Structural: adapter, bridge, composite, decorator, facade, proxy, flyweight
 * 
 * Behavioural: visitor, strategy, observer, state, template method, command, 
 * 				memento, iterator, mediator, chain of responsibility, command
 * 
 * Abstract factory: 
 *   - easy switch application between different implementations of services/abstractions
 *   - minimize knowledge of client code about concrete classes
 * 
 * Builder:
 *   - easy and structured way to create complex objects
 *   - abstract construction of a complex object from its representation
 * 
 * Prototype
 *   - simplify creation of complex objects
 *   - minimize added cost of creating a new instance
 *   
 * Singleton
 *   - ensure that only one instance of the class exists in the application in runtime
 * 
 * Wrapper (Adapter)
 *   - translate interface of one class into the way acceptable for another class
 *   - separate client code from knowledge about concrete service interface
 * 
 * Bridge
 *   - decouple abstraction from its implementation so the two can vary independently
 *   
 * Composite
 *   - treat individual objects and compositions(groups) uniformly
 * 
 * Decorator
 *   - extend/change behaviour of an object not changing its class
 *   
 * Facade
 *   - provide clear and simple interface to a class library
 *   - provide an interface to subsystem
 *   
 * Proxy
 *   - give a client "handler" to access functionality where client can not be 
 *     supplied with the real instance of the service
 *   - intervene into client-server communication
 * 
 * Flyweight
 *   - share identical data structures to minimize memory/resource footprint
 *   - samples string interning, various caching
 *   
 * Visitor
 *   - define a new operation without changing the classes of the elements on which it operates
 * 
 * Strategy (Policy)
 *   - select algorithm behaviour in runtime
 *   
 * Observer (Listener)
 *  
 * State
 *   - change behaviour of an object when its state changes
 *   
 * Template method
 *   - define skeleton of the algorithm
 *   - allow subsclasses modify steps of the algorithm
 *   
 * Memento
 *   - without violating encapsulation, capture and externalize an object's internal state 
 *     so that the object can be restored to this state later
 *     
 * Iterator
 * 
 * Mediator
 *   - encapsulate how a set of objects interact
 *   - keep objects from referring to each other explicitly despitethe fact they participate in joint workflow
 *   
 * Chain of Responsibility
 *   - avoid coupling the sender of a request to its receiver by givint more 
 *     than one object a chance to handle the request
 * 	 - chain the receiving objects and pass the request along  the chani 
 * 	   until an object handles it
 * 
 * Command
 *   - encapsulate data required to call a method (for remote calls or delayed calls)
 * 
 * ARCHITECTURE SNIPPETS
 * 
 * Service Oriented Architecture
 * Dependency Injection/Inversion of Control(IoC)
 * Service Availability Heartbeats
 * Active-Active Processing
 * None Acknowledgement Protocols
 * 
 * 
 * HOMEWORK
 * design cache
 * get(String)
 * put(String,Object)
 * 
 * clients with nearCache
 * 
 * clients can read
 * 
 * server can read, write
 * 
 * if server do put, then clients see it
 * if starts then snapshot of data then all updates
 * 
 * deadline on Wednesday
 * 
 * 
 * 
 * 
 * 
 * 
 */

public class DesignPatternsLecture {
	
}
